Programmers may write programs to perform particular intended operations. However, when implemented, programs often fail to perform as intended. For example, a program may not perform the intended operation, and/or may even perform an unintended operation. Therefore, a programmer conventionally debugs a program, e.g., if the programmer discovers a program error. By debugging the program, the programmer may discover, e.g., where a variable is set with an incorrect value or where a program incorrectly enters or exits a logic path, such as a “for-each” loop.
Some programming languages present program elements as nodes in a tree-like structure. An example of such a program is an Extensible Stylesheet Language (XSL) program. For example, a program variable of an XSL program may be a child node of a parent node, i.e., another program element, such as another program variable. For example, a variable “contact” may have child nodes. The child nodes may be a variable “name” and/or a variable “address.” Each of these child nodes may have further child nodes. For example, variables “first_name” and “last_name” may be child nodes of variable “name.”
A logic path may be another type of programming element. A logic path of a program may be, for example, an application of a template to input of the program, a “for-each” loop, a “when” condition, an “if” condition, etc. These programming elements may also be presented in a tree-like structure. For example, a “for-each” loop may be nested. Thus, one loop may be within another loop. The inner loop may be viewed as a child node of the outer loop.
To debug a program, a programmer may input the program into a debugging system. The debugging system may output debugging comments that indicate the manner in which the program is executed. In a conventional debugging system for debugging a program, e.g., an XSL program, such as an Extensible Stylesheet Transformations (XSLT) program, the programmer may select a particular line of the program's code. Upon initiation, the debugging system may execute the program until the debugging system reaches the selected line and may output information about the program at the selected line. However, this debugging system requires the programmer to tediously select numerous program lines until the programmer finds the error causing program code. Furthermore, this debugging system does not provide the programmer with information regarding the overall program operation simultaneously. Rather, such information is provided piecemeal, and the programmer must determine the program's overall operation from the provided piecemeal information.
Alternatively, it is conventional for a programmer to add debugging program code to a program in order to debug the program. For example, a programmer may add to an XSL program an <xsl:message> tag to output a debugging comment. Such debugging program code may output debugging comments, e.g., that indicate information about the program element, such as a variable's value, at a point of the program's execution that corresponds to the portion of program code to which the programmer added the debugging code. The debugging program code may send the debugging comments, e.g., to a printout or to a computer screen, located in an output location different than that of the program's main output, i.e., the output that pertains to the intended operation of the program. For example, the <xsl:message> tag sends an output comment to Standard Error on Unix, a location that is different than the location to which the main output is sent. However, this manner of program debugging requires a programmer to manually enter debugging code into an XSL program. Furthermore, the outputted debugging comments are not integrated with the program's intended output. Consequently, some, if not all, of the program context of the debugging comments is not provided.
Furthermore, a programmer may debug a program, e.g., in order to ultimately discover which section of code within a program, e.g., which node of a tree-structured program, causes the incorrect results. Conventionally, debugging comments are output without an indication of the particular node to which the comment relates. Therefore, even if the debugging comments are integrated with the output of the program being debugged, it is still required for the programmer to keep track of the generated comments to determine the node to which a particular comment pertains.
It is conventional to provide an indication of the columns and lines of the code section to which a generated comment pertains. However, such information does not indicate a node to which the comment relates. It is required for the programmer to read the referenced code and determine how the relevant code relates to the program's tree-structure.
Additionally, some programming languages, such as XSL, do not provide the capability of maintaining state information of the executed code. As used herein, state information refers to information regarding a state or sequence of a program's execution. For example, XSL does not provide the capability to keep track of the columns and lines of execution or to keep track of the nodes that have been executed.
Consequently, code of the program being debugged, e.g., the XSL program, is conventionally not modified to generate the debugging comments that include state information. Instead, to generate the debugging comments that indicate the columns and lines of the corresponding code, it is conventional to execute debugging code that is external to the program being debugged. However, the debugging comments are therefore not integrated with the output of the program being debugged. For example, the debugging comments may be provided in one window and the output of the program being debugged may be provided in a different window. It is then required for the programmer to determine how the debugging comments relate to the output of the debugged program.
Generation of code in an XSLT program for outputting debugging comments integrated with a main output of the XSLT program is discussed in Joseph Kesselman, “Style stylesheets to extend XSLT, Part 1,” http://www-106.ibm.com/developerworks/xml/library/x-styless1/, (May 6, 2003), and in Joseph Kesselman, “Style stylesheets to extend XSLT, Part 2,” http://www-106.ibm.com/developerworks/xml/library/x-styless2/, (May 13, 2003), (collectively “Kesselman”). However, Kesselman discusses generation of code that, when executed, will generate debugging comments for only a template element of a program. Kesselman does not provide a way to trace other program elements, such as program variables. Furthermore, Kesselman does not provide a way to generate debugging comments that indicate the particular sections of code to which the comments pertain. For example, the columns and lines of code that correspond to the debugging comments are not provided. Furthermore, the debugging comments do not indicate the particular nodes to which the comments relate.
It is therefore desirable to provide a system and method for automatically generating debugging comments for a program of a tree-structured language that does not maintain state information, such that the debugging comments are integrated with a main output of the program, and provide state information.